[iOS]创建界面方法的讨论


以前在入门的时候,找的入门书籍上编写的 demo 都是基于 Storyboards 拖界面的。后来接触公司项目,发现界面都是用纯代码去写复杂的 autoLayout 的。再然后,领导给我发了个 Masonry 库去看,依然是手写代码布局界面,但效率高了不少。工作一段时间,看了很多博客,也看了一些书,发现用纯代码写界面的很少,于是就在 Google 上搜 Storyboards 有什么好处,最后发现了一篇非常好的文章。在此提炼文章的一些观点,同时表达一下自己的观点。

文章链接:iOS User Interfaces: Storyboards vs. NIBs vs. Custom Code
文章介绍了三种构建界面的方法,并对不同方法分别讨论了优缺点。

其实对于这几种方法,没有最好,只有最适合。

总结下来就是 Storyboards 是一个容易观察并且使用简单的 iOS UI 设计工具。它也消除了固定的创建控件的模板代码,但导致了很严重的灵活性的缺失。NIBs 对于 single view 来说提供了很大灵活性,但没有视觉流(个人猜测是 view controller 的切换)。灵活性最大的方案就是纯代码布局,但纯代码并不是那么直观,也没有那么容易。

同样的话题,在唐巧的博客里,也讨论过这个问题:iOS 开发中的争议(二)

其中比较有说服力的一段是他分析了100多个 App 包含 xib 文件的个数,大概推测出很多著名的 App 里大部分界面都是手写来完成的。

同时他也提出了自己的建议:

  • 对于复杂的、动态生成的界面,建议使用手工编写界面。
  • 对于需要统一风格的按钮或UI控件,建议使用手工用代码来构造。方便之后的修改和复用。
  • 对于需要有继承或组合关系的 UIView 类或 UIViewController 类,建议用代码手工编写界面。
  • 对于那些简单的、静态的、非核心功能界面,可以考虑使用 xib 或 storyboard 来完成。

呐最后我个人也是偏好使用纯代码布局的,并不是因为我一直是这么做的,而是有以下原因:

  1. 纯代码布局最让人诟病的就是代码量太大,的确,我之前用 autoLayout 的时候每写一个 constrains 就要好几行代码,一个控件有几个约束关系的话就要写几个 constrains,这个代码量一下就上去了。但现在有开源的 Masonry 库,对于 Swift 也有相应的库,所以对于代码量以及学习难度来讲,纯代码布局这部分的缺陷完全能够被弥补。
  2. 纯代码写的界面容易控制,这个容易控制是说,你每增加一个控件,一个约束在代码上就可以很直观的显示出来,因为每写一行代码你自己就会很清楚。而对于 Storyboards 来讲,控件的属性界面密密麻麻一大片,不管你改不改,那些数据都显示在那里,有时候你忘记改了哪些东西你都会在属性栏里一个一个去找。比如我把 view 的背景色从 grayColor 改成了 lightGrayColor,那我从代码上就可以很直观的看到这一句 view.backgroundColor = [UIColor lightGrayColor],但如果在 Storyboards 里,我就要去找背景色这一栏,还要分辨出灰色和浅灰色。
  3. 最后,就是代码的复用。比如写一个复杂的 tableViewCell ,用 Storyboards 去拖界面的话,就会看到视图上面有一堆控件和布局,如果我想在哪天复用这个 cell 并做一些布局修改的话,便又要重新拖放,如果有响应事件的话,还要重新给新建的类连线,想想这个工作量,不出错都难。而对于手写界面来说,写一个控件就封装在一个类里面,需要复用了,继承一下或者复制粘贴到别的工程即可使用,就算有响应事件,写几个 protocol 做反馈就解决了。
  4. 最最后,我想起来以前上学搞 MFC 的时候,那时候也有关于手写界面还是拖界面的讨论,当时一个很有说服力的评论是,手写界面可以锻炼你对 MFC 程序的理解,可能你还是无法知道 MFC 的实现原理,但你会很熟悉 MFC 的实现过程(大概是这意思)。这一点我觉得在 iOS 上也适用。比如说按钮事件,用 Storyboards 就是鼠标一拖,连一条线出来,系统就生成了一段事件代码,而你只要填代码就可以。我觉得这对于学习 iOS 不是一件好事情,虽然说我现在也不是非常了解 iOS 底层的一些实现原理,但通过手写界面,手动添加事件,我知道这些东西是怎么添加的,添加的东西和其他类之间的关系是什么。所以手写界面对学习 iOS 还是有一些帮助的。

文章作者: Wossoneri
版权声明: 本博客所有文章除特別声明外,均采用 CC BY-NC 4.0 许可协议。转载请注明来源 Wossoneri !
评论
  目录